获取远程配置，并设置到sessionSampleRate - #18
Conversation
guguji5
commented
Aug 25, 2026
guguji5
commented
小程序里flashcatRum.init 内传入 remoteConfiguration: true,后，有获取config的请求发送。也输出了一下log。目前好像还没数据，等有数据了我会再验证一下
Duplicate each success notification step to post to a second DingTalk robot via the DING_TALK_TOKEN_2 / DING_TALK_SECRET_2 secrets. Failure notifications are unchanged and still go to the original robot only.
…-group ci: also send release success notifications to a second DingTalk group
The release workflow treated the DingTalk notification as a build gate: when the robot API rejects a message -- for example once its per-minute rate limit is exhausted -- the notification step failed and marked an otherwise successful publish as failed. Set `ignoreError` on every DingTalk step so a rejected notification is reported as a warning instead of failing the job. The publish outcome no longer depends on the notification channel.
The repository formats YAML with `singleQuote`, so the double-quoted value failed the format check.
…rror ci: do not fail a release when the DingTalk notification fails
The other four SDKs that carry this feature — web, iOS, Android and HarmonyOS — all spell the switch `remoteConfigurationEnabled`. A host writing the same integration twice should not have to remember that one platform spells it differently, and a boolean reads better with the suffix than as a bare noun. Renamed before any release, so no integration has to change. The JSDoc that came with it is translated, since everything git-facing here is English.
|
Reviewed this against the four other SDKs that carry the same feature (web, iOS, I pushed one commit (86a784b) rather than leave it as a comment, because it is a
Build and all 269 tests pass on the renamed branch. Three things still missing, compared with the other platformsThe commit message already says this slice only wires 1. getRemoteConfig: () => Record<string, unknown> | undefinedReference: browser-sdk — same language and the same architecture as this SDK. 2. Reference: browser-sdk, same file. 3. Copy the HarmonyOS contract here, not the web one. Web's callback also carries interface BeforeSamplingContext {
readonly sessionSampleRate: number // 0..100, console's where set, init's otherwise
readonly custom: Record<string, unknown> | null
}
type BeforeSamplingCallback = (context: BeforeSamplingContext) => number | undefinedTwo things the HarmonyOS implementation gets right and are worth copying exactly:
Reference: One small thingThe PR title is in Chinese. Everything git-facing in this repo — titles, bodies, |
|
Extend remote configuration beyond session sampling so hosts can drive their own decisions and force collection during support flows: - parse the top-level `custom` and cache it atomically with the sampling snapshot and ETag, exposed via `getRemoteConfig()` - add `setForcedSession()` to mark the next new Session as collected without touching the current one or changing sample rates - add the `beforeSampling` callback to adjust the rate of the Session being created, with safe fallback on invalid results and thrown errors Also export `BeforeSamplingContext` and `BeforeSamplingCallback` from the package entry, and fix the README still documenting the removed `remoteConfiguration` switch instead of `remoteConfigurationEnabled`.
点击结束当前session后，可以拿到，，beforeSampling的callback参数
|
下发的也会生效～
|
The configuration was requested once, at start-up. A miniprogram process routinely outlives a session: it is backgrounded and foregrounded for hours without a cold launch, so every session drawn after the first went on using whatever the console had published when the app first opened. That is the one promise the feature makes — a change takes effect at the next new session — and on this platform it held only for the session that happened to be first. A renewal now asks again, reporting the version the renewed session was drawn under. The response lands for the session after it, which is the same ordering the other platforms have. Alongside it, three things the extra trigger made matter: Only one request is in flight at a time. Start-up and a renewal can land together on a cold start, and nothing stopped both from going out. A schema version this build cannot read is treated as a settled answer rather than a failure to retry. Asking again only fetches the same refusal. The kill switch keeps the version that set it. Every knob goes back to what the app was initialised with, but clearing the version too meant the next request reported none, and the console could not tell a client that had taken the kill switch from one that had never heard of it.
Two tests on this branch contradicted each other: one asserted every console message carries the "[FlashCat RUM]" prefix, the other asserted this particular line carries "[FlashCat RUM SDK]". Both were failing, and had been since they landed, because no prefix can satisfy them at once. The single odd line is brought in line with the other eight, and the test that pinned it to the odd form is corrected. The suite goes green.
…le process Two problems with the guard added a moment ago, both found reviewing that change rather than the code it fixed. The guard was a flag, released only by a callback. The request timeout is an option handed to the host, and nothing guarantees it answers: a request whose success and fail callbacks both go missing left the flag set for the life of the process, and every later session renewal was dropped without a sound. That is worse than what it replaced, where a lost callback cost one fetch. It is now the moment the request started, and a chain older than the timeout no longer counts as in flight — no timer to arm, none to cancel, and the next session renewal simply asks again. The kill switch kept the version that switched it off, but only in memory: the same call cleared the cache. A miniprogram process is reclaimed far more readily than an app, and on the next launch the client reported no version at all — indistinguishable, to the console, from one that never heard about the change. The kill-switch state is written instead of cleared. Nothing stale can come back with it: every knob in it is already the initialization value.
2 participants
